Subject: X.25 QLLC DLC and "NRM"

From: "jim (j.) cobban" <[email-masked]>
Date: Wed, 2 Aug 1995 17:06:00 -0400

Although I have not been able to find any formal statement in any document
from IBM on this question, from observation it would appear that all
implementations of QLLC are treated as NRM.  That is the ABM bit is NOT set
in XIDs.  This appears to be a consequence of the original implementation of
QLLC, in NPSI, as an SDLC emulation.  However this decision is causing us
great difficulty with our implementation.

The crucial area is described in the APPN Architecture Reference on pages
9-136 through 9-138.  In particular:

  "In the NRM XID protocol, receiving an XID after sending the mode-setting
  command must be prevented.  This is done by having one side not respond
  (send an XID) to a received XID when it determines that it will be
  secondary".

The second sentence documents a kluge which was inserted into the
architecture to deal with the "problem" described in the first sentence.  I
describe the implementation as a "kluge" because obviously a much simpler
solution would have been to ignore the received XID in both ABM and NRM. 

In NRM a secondary station can only transmit if it has ownership of the P
bit.  On a peer SDLC link, during the XID negotiation, both stations are
combined stations until a role is established.  That means both can transmit
command frames carrying the P bit at will.  In effect there are TWO P bits
flowing back and forth.  When one of the stations determines that it is
secondary, it has just received a P bit from the other end, and therefore
according to the rules of NRM, it has the right to transmit.  The APPN design
kluge in question is a recognition that there may be one more P bit
floating around, and therefore the brand-new secondary chooses to discard
this P bit without acting on it in order to converge back to the normal SDLC
behavior in which there is only a single P bit on the line.

Now the problem that I face is that QLLC/X.25 is NOT really NRM.  Indeed the
link layer of X.25 _is_ ABM.  More importantly QLLC/X.25 is a completely
reliable data link layer.  If one end sends a packet, for example Q-XID, then
it is guaranteed that either that packet will be delivered, or else the
virtual circuit will fail.  There is no possibility of a silent non-delivery
of the packet.

So, in the case in question, one end of the QLLC VC has sent a Q-XID which is
delivered to the other end.  CS at that end decides, for whatever reason,
that it is going to assume the secondary role.  But, because of the universal
convention that QLLC is NRM (when it is NOT), CS then refuses to respond,
expecting that error recovery at the "primary" end of the link will cause the
XID to be retransmitted.  But in the case of QLLC since the primary end has
been guaranteed delivery, the XID is not retransmitted.  The result is that
the connection hangs!

In a packet network every packet is charged for.  Therefore SNA packet
assembler/disassemblers (PAD) perform error recovery locally, and only
transmit packets if they convey information which the other end needs.  In
particular if PADs receive a U command which is identical to the last U
command received on the same link connection, they discard it as a duplicate,
because they know that the previous copy has been delivered.

I am completely at a loss at how I am to compensate for this in a portable
manner.

I could compensate for this feature in CS by having the DLC start a timer to
repeat the MU_XID signal to CS if no response is received from CS or no
Q packet is received from the VC in a reasonable time.  But what
constitutes "reasonable"?  Do I have to annoy my customers by making them
provision another retry timer to get around this design feature in the
architecture? Further that may solve the hang if my node is the one which
negotiates to secondary, but what if the node at the other end is expecting
ME to retransmit the Q-XID over the virtual circuit?

I could compensate for this feature by telling CS that the QLLC DLC
implementation is actually ABM.  The DLC would then flip the ABM support bit
in each XID as it passed through in order to keep the far end happy.  However
this creates an opening in which a Q-XID could arrive at a remote QLLC PAD 
in the interval after it had sent a Q-SM.

Why have the SDLC implementors put up with a feature which demands that
there be error recovery, and possibly delays, on almost every link
activation, even though there is nothing physically wrong with the link? 
Why is it so important to treat an XID coming out of order as a catastrophic
failure?  Why would the APPN architects rather write 3 pages of architecture
documentation, and product developers thousands of lines of special handling
code rather than just ignore that unprintable XID response?

It is very urgent that I solve this problem.